In various computer systems, historical log data is maintained in, for instance, log files for use in system recovery, problem determination and/or system maintenance. Typically, these log files have a limited amount of capacity to retain the historical data. After the capacity is met, at least some of the data records are moved from the log files to external storage devices, such as direct access storage devices (DASD), thereby providing additional space in the log files for more data.
At some point, data within the log files and/or on the external storage devices is no longer needed. For example, there is no need to keep the data once it passes its retention requirements. The saving of data past its usefulness adversely affects system performance in a number of ways. For instance, when unnecessary data is retained and a log file needs to be browsed to recover logged data during recovery of a failure, the browser may have to deal with potentially large amounts of unnecessary data, thereby slowing down the recovery process. Additionally, when the saving of unwanted data records requires the use of external storage devices, which typically provide slower access to the data, the reading of the data takes longer, thus, affecting system performance.
Therefore, it is beneficial to delete any unnecessary data from the log files. This is accomplished by compressing the log files and then physically deleting any entries that can be deleted. When a log file is used by various systems of a multisystem environment, each of the systems is responsible for compressing and deleting its unwanted entries.
When the systems of the multisystem environment are processing at different transaction rates, however, and the slower system does not adequately compress the log file at a rate commensurate with the faster system, the slower system adversely affects the performance of the faster system. This is true regardless of whether the reason for the disparity in transaction rates is hardware performance characteristics or work load differences. Thus, the faster system potentially has many more elements in the log file than the slower system, and the elements of the faster system can be separated by a single element written by the slower system. This problem may be exacerbated when there are several fast systems and only one slow system.
Based on the foregoing, a need exists for a capability that provides for the pacing of the frequency at which a system compresses a multisystem log file. A further need exists for a capability that allows each system to adjust its compression rate based on the compression rates of the other systems, thus ensuring a minimal sized log file. A further need exists for a pacing technique that allows the frequency of compression to be adjusted in real-time based on the current transaction rates of the systems connected to the log file.